GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Cross-Site-Request-Forgery</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Cross-Site-Request-Forgery</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p>Eine <b>Cross-Site-Request-Forgery</b> (meist <b>CSRF</b> oder <b>XSRF</b> abgekürzt, deutsch etwa „<a href="Website" title="Website">Website</a>übergreifende Anfragenfälschung“, auch <b>Session-Riding</b> genannt) ist ein Angriff auf ein <a href="Computer" title="Computer">Computersystem</a>, bei dem der Angreifer eine Transaktion in einer <a href="Webanwendung" title="Webanwendung">Webanwendung</a> durchführt. Dies geschieht nicht direkt, sondern der Angreifer bedient sich dazu eines Opfers, das bei einer Webanwendung bereits angemeldet sein muss. Dem <a href="Webbrowser" title="Webbrowser">Webbrowser</a> des Opfers wird ohne dessen Wissen eine <a href="Hypertext_Transfer_Protocol#HTTP-Anfragemethoden" title="Hypertext Transfer Protocol">HTTP-Anfrage</a> untergeschoben. Der Angreifer wählt die Anfrage so, dass bei deren Aufruf die Webanwendung die vom Angreifer gewünschte Aktion ausführt.

</p><p>Das Sicherheitsproblem ist auf die <a href="Zustandslosigkeit" title="Zustandslosigkeit">Zustandslosigkeit</a> von HTTP zurückzuführen, da nach einmaliger Authentifizierung der Browser implizit jedes Mal seine Sitzungsdaten an den Server sendet.

</p><p>Im Artikel hier wird vereinfacht vom <i>Cookie</i> gesprochen, wenn eine <i>Sitzung</i> (insbesondere ein Sitzungsbezeichner) gemeint ist. CSRF tritt jedoch nicht nur bei Cookie-basierter, sondern auch bei <a href="HTTP-Authentifizierung#Basic_Authentication" title="HTTP-Authentifizierung">Basic</a>- bzw. <a href="HTTP-Authentifizierung#Digest_Access_Authentication" title="HTTP-Authentifizierung">Digest</a>-Authentifizierung auf.

</p>

<div class="mw-heading mw-heading2"><h2 id="Geschichte">Geschichte</h2></div>

<p>Bereits im Oktober 1988 veröffentlichte Norm Hardy ein Dokument, in dem er den Sachverhalt von Vertrauen auf Anwendungsebene diskutierte und diesen „a Confused Deputy“ (dt. etwa „einen verwirrten Stellvertreter“) nannte. Im Jahr 2000 wurde auf der Sicherheits-Mailingliste <a href="Bugtraq" title="Bugtraq">Bugtraq</a> erörtert, wie <a href="Zope_(Webanwendungsserver)" title="Zope (Webanwendungsserver)">ZOPE</a> von einem confused-deputy-Problem betroffen war, welches man heute als CSRF-Sicherheitslücke einstufen würde. Später dann, im Jahr 2001, veröffentlichte Peter Watkins auf Bugtraq einen Beitrag<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> zur Diskussion „The Dangers of Allowing Users to Post Images“ (dt. etwa „Gefahren, wenn Anwender Bilder einbinden dürfen“), mit der er den Ausdruck „Cross-Site-Request-Forgery“ prägte.

</p>

<div class="mw-heading mw-heading2"><h2 id="Beispiele">Beispiele</h2></div>

<p>Ein recht harmloses Beispiel einer CSRF wäre ein Link auf der Webseite des Angreifers zu der Abmelden-Funktion auf der Wikipedia:

</p>

<pre>https://de.wikipedia.org/w/index.php?title=Spezial:<b>Userlogout</b>

</pre>

<p>Wird einem in der Wikipedia angemeldeten Benutzer dieser Link untergeschoben, sodass sein Browser diese Anfrage absetzt, wird er ohne eigenes Zutun von der Wikipedia abgemeldet, vorausgesetzt die Webanwendung auf Wikipedia hat keinen Schutz gegen CSRF-Angriffe. In der Realität muss die Abmeldung bei der Wikipedia hier allerdings noch einmal bestätigt werden und der eigentliche Logout-Vorgang funktioniert über eine <a href="Hypertext_Transfer_Protocol#HTTP_POST" title="Hypertext Transfer Protocol">POST</a>-Anfrage.

</p><p>Schwerwiegender wäre eine solche URL bei der Benutzerverwaltung einer nicht öffentlichen Seite. Zum Beispiel könnte der Angreifer mit

</p>

<pre>https://www.example.com/admin.php?action=<b>new_user</b>&<b>name</b>=baduser&<b>password</b>=geheim

</pre>

<p>einen neuen Benutzer anlegen und sich somit unberechtigten Zugang zu der entsprechenden Webanwendung verschaffen, wenn er es schafft, dem Administrator der Webanwendung diese HTTP-Anfrage unterzuschieben und dieser angemeldet ist.

</p>

<div class="mw-heading mw-heading2"><h2 id="Angriffsvektoren">Angriffsvektoren</h2></div>

<p>Damit der Angreifer eine Cross-Site-Request-Forgery ausführen kann, muss er den Webbrowser des Opfers dazu bringen, einen oder mehrere vom Angreifer manipulierte HTTP-Anfragen auszuführen. Hierzu gibt es mehrere <a href="Angriffsvektor" title="Angriffsvektor">Angriffsvektoren</a>:

</p>

<div class="mw-heading mw-heading3"><h3 id="Cross-Site-Scripting">Cross-Site-Scripting</h3></div>

<p>Mittels <a href="Cross-Site-Scripting" title="Cross-Site-Scripting">Cross-Site-Scripting</a> (XSS) kann ein Angreifer z. B. einen img- oder script-Tag in die Webanwendung einbauen, der einen HTTP-Request verursacht. Vor dieser Methode kann sowohl die <a href="Same-Origin-Policy" title="Same-Origin-Policy">Same-Origin-Policy</a> als auch das <a class="mw-selflink-fragment" href="#SameSite-Attribut">SameSite-Attribut</a> nicht schützen, da die Anfragen von innerhalb der Webanwendung ausgehen. Die Methode mit einem script-Tag erlaubt es dem Angreifer sogar, auch <a href="Hypertext_Transfer_Protocol#HTTP_POST" title="Hypertext Transfer Protocol">POST</a>-Requests zu senden. Vor dieser Bedrohung schützen die unten stehenden Abwehrmaßnahmen allerdings nicht, denn das eigentliche Problem liegt hier in der XSS-Lücke.

</p>

<div class="mw-heading mw-heading3"><h3 id="Unterschieben_der_URL">Unterschieben der URL</h3></div>

<p>Existieren in einer Webanwendung GET-Schnittstellen, die Daten am Server verändern, ist es möglich, ein eingeloggtes Opfer mittels <a href="Social_Engineering_(Sicherheit)" title="Social Engineering (Sicherheit)">Social Engineering</a> dazu zu bringen, auf einen Link zu klicken, durch den das Opfer unwissentlich dann eine vom Angreifer gewünschte Aktion auf der Webseite ausführt.

</p><p>Alternativ könnte der Angreifer solch eine URL z. B. in einem img-Tag auf einer eigenen Webseite verstecken und das Opfer dann auf diese Seite locken, wodurch die GET-Anfrage ausgeführt würde.

</p>

<div class="mw-heading mw-heading3"><h3 id="Schädliche_Formulare"><span id="Sch.C3.A4dliche_Formulare"></span>Schädliche Formulare</h3></div>

<p>Lockt ein Angreifer ein Opfer auf die eigene Webseite, kann er ein verstecktes <a href="Webformular" title="Webformular">Formular</a> in die Webseite einbauen, das einen POST-Endpunkt einer anderen Webseite, auf der das Opfer eingeloggt ist, als Ziel hat. Die <a href="Same-Origin-Policy" title="Same-Origin-Policy">Same-Origin-Policy</a> verhindert zwar lesenden Zugriff auf andere Webseiten, aber die Anfrage wird trotzdem zuerst abgeschickt, um auf <a href="Cross-Origin_Resource_Sharing" title="Cross-Origin Resource Sharing">CORS</a>-Header zu prüfen, und erst dann wird die Antwort gegebenenfalls verworfen. Der Server hat diese dann bereits empfangen und damit die vom Angreifer gewünschte Aktion ausgeführt.

</p><p>Bei vielen Arten von durch <a href="JavaScript" title="JavaScript">JavaScript</a> veranlassten POST-Anfragen wird vorher eine Preflight-Check-Anfrage gesendet, die die Kontrolle der CORS-Header ermöglicht, ohne die eigentliche POST-Request zu senden. Bei Formularen ist dies allerdings aus Gründen der Rückwärtskompatibilität nicht der Fall, weswegen dieser Angriff auch in modernen Browsern möglich ist, indem man mittels JavaScript ein verstecktes Formular erstellt und absendet.

</p>

<div class="mw-heading mw-heading2"><h2 id="Abwehrmaßnahmen"><span id="Abwehrma.C3.9Fnahmen"></span>Abwehrmaßnahmen</h2></div>

<p>Je nach Angriffsvektor ist entweder der Benutzer für clientseitige oder der Betreiber der Webanwendung für serverseitige Abwehrmaßnahmen gegen eine Cross-Site-Request-Forgery zuständig.

</p>

<div class="mw-heading mw-heading3"><h3 id="Serverseitig">Serverseitig</h3></div>

<div class="mw-heading mw-heading4"><h4 id="Nutzung_korrekter_HTTP-Methoden">Nutzung korrekter HTTP-Methoden</h4></div>

<p>Die Sicherheitskonzepte der Browser basieren darauf, dass <b>GET</b>-Anfragen zu keiner Veränderung von Daten auf dem Server führen. Sollen Daten verändert werden, so sollten dafür <b>POST</b>-, <b>PUT</b>-, <b>PATCH</b>- oder <b>DELETE</b>-Schnittstellen verwendet werden.

</p><p>Dies verhindert einfache Angriffe wie ein <a class="mw-selflink-fragment" href="#Unterschieben_der_URL">Unterschieben der URL</a>, da das Anklicken eines Links erstmal nur eine GET-Anfrage auslöst, schützt aber nicht vor raffinierteren Angriffen wie z. B. durch <a class="mw-selflink-fragment" href="#Schädliche_Formulare">Schädliche Formulare</a>.

</p>

<div class="sieheauch" role="navigation" style="font-style:italic;"><span class="sieheauch-text">Siehe auch</span>: <a href="Hypertext_Transfer_Protocol#HTTP-Anfragemethoden" title="Hypertext Transfer Protocol">Hypertext Transfer Protocol#HTTP-Anfragemethoden</a></div>

<div class="mw-heading mw-heading4"><h4 id="SameSite-Attribut">SameSite-Attribut</h4></div>

<p>Das SameSite-Attribut spezifiziert, wie ein Cookie beim Aufruf der Seite aus dem Zugriffskontext anderer Seiten verwendet werden darf. In heutigen Browsern stellt SameSite=Strict einen wirksamen Schutz gegen CSRF dar. Falls auf der Seite keine sensitiven Aktionen durch GET-Requests ausgeführt werden können, reicht auch SameSite=Lax aus.

</p><p>SameSite=Lax ist in modernen Browsern bereits die Standardeinstellung für Cookies. Daher reicht es eigentlich aus, dass die HTTP-Methoden korrekt genutzt werden (siehe oben). Da dieser Standardwert sich aber erst in den letzten Jahren durchgesetzt hat, ist das explizite Setzen des Attributs noch notwendig.

</p><p>Falls explizit stark veraltete (unsichere) Browser verwendet werden, müssen jedoch zusätzlich weitere Sicherheitsvorkehrungen (wie CSRF-Tokens) getroffen werden.

</p><p>Außerdem bietet SameSite nur Schutz, wenn es für einen Angreifer nicht möglich ist, diesen unter derselben eTLD+1 (also dem Domainteil bis ein Level vor einer in der <a href="Public_Suffix_List" title="Public Suffix List">Public Suffix List</a> festgelegten Endung z. B. „example.org“ bei „test.example.org“) zu hosten. Wären beispielsweise <a href="GitHub#GitHub_Pages" title="GitHub">GitHub Pages</a> nicht auf „github.io“, sondern auf „github.com“ gehostet, würde das SameSite-Attribut als Schutz für <a href="GitHub" title="GitHub">GitHub</a> nicht ausreichen.

</p>

<div class="mw-heading mw-heading4"><h4 id="Synchronizer_Token_Pattern_(STP)"><span id="Synchronizer_Token_Pattern_.28STP.29"></span>Synchronizer Token Pattern (STP)</h4></div>

<p>Bei STP wird ein sogenanntes Page-Token, meistens eine Zahl oder eine Zeichenkette, in einem Hidden-Field auf der Seite eingebunden.

</p>

<div class="mw-highlight mw-highlight-lang-html mw-content-ltr" dir="ltr"><pre><span></span><span class="p"><</span><span class="nt">input</span> <span class="na">type</span><span class="o">=</span><span class="s">"hidden"</span> <span class="na">name</span><span class="o">=</span><span class="s">"csrftoken"</span> <span class="na">value</span><span class="o">=</span><span class="s">"KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt"</span> <span class="p">/></span>

</pre></div>

<p>Ohne weitere Lücken in der Webanwendung ist dieses Hidden-Field für den Angreifer nicht auslesbar. Insbesondere eine <a href="Cross-Site-Scripting" title="Cross-Site-Scripting">XSS-Schwachstelle</a> kann jedoch den CSRF-Schutz aushebeln. Letzteres gilt selbst dann, wenn die XSS-Schwachstelle bloß in einer anderen Anwendung auf derselben Domain existiert.<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Wie das Feld gesetzt wird, ist abhängig vom verwendeten Framework.

</p><p><b>Beispiel in ASP.NET MVC</b>

</p><p>In <a href="ASP.NET_MVC" title="ASP.NET MVC">ASP.NET MVC</a> werden alle Forms automatisch mit einem Hidden-Field mit dem Anti-CSRF-Token versehen:

</p>

<div class="mw-highlight mw-highlight-lang-csharp mw-content-ltr" dir="ltr"><pre><span></span><span class="n">@using</span><span class="w"> </span><span class="p">(</span><span class="n">Html</span><span class="p">.</span><span class="n">BeginForm</span><span class="p">(</span><span class="s">"ChangePassword"</span><span class="p">,</span><span class="w"> </span><span class="s">"Manage"</span><span class="p">))</span>

</pre></div>

<p>Alternativ lässt sich dieses auch manuell setzen:

</p>

<div class="mw-highlight mw-highlight-lang-csharp mw-content-ltr" dir="ltr"><pre><span></span><span class="o"><</span><span class="n">form</span><span class="w"> </span><span class="n">action</span><span class="o">=</span><span class="s">"/"</span><span class="w"> </span><span class="n">method</span><span class="o">=</span><span class="s">"post"</span><span class="o">></span>

<span class="w"> </span><span class="n">@Html</span><span class="p">.</span><span class="n">AntiForgeryToken</span><span class="p">()</span>

</pre></div>

<p>Zudem gibt es in ASP.NET Core mit <code>Microsoft.AspNetCore.Antiforgery</code> die Möglichkeit das Token auch global zu konfigurieren:

</p>

<div class="mw-highlight mw-highlight-lang-csharp mw-content-ltr" dir="ltr"><pre><span></span><span class="n">services</span><span class="p">.</span><span class="n">AddAntiforgery</span><span class="p">(</span><span class="n">options</span><span class="w"> </span><span class="o">=></span><span class="w"> </span><span class="p">{</span>

<span class="w"> </span><span class="n">options</span><span class="p">.</span><span class="n">FormFieldName</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">"csrftoken"</span><span class="p">;</span>

<span class="w"> </span><span class="n">options</span><span class="p">.</span><span class="n">RequireSsl</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="k">true</span><span class="p">;</span>

</pre></div>

<p>Die Validierung des Tokens muss auf allen MVC-Controllern bzw. Methoden erfolgen, welche eine Nebenwirkung besitzen. Hierzu dienen drei Filter, welche als Attribute auf den entsprechenden Controllern bzw. Methoden gesetzt werden können:

</p>

<th>Attribut</th>

<th>Funktion

</th></tr>

<tr>

<td><code class="mw-highlight mw-highlight-lang-csharp mw-content-ltr" dir="ltr"><span class="na">[ValidateAntiForgeryToken]</span></code>

</td>

<td>Validiert das CSRF-Token

</td></tr>

<tr>

<td><code class="mw-highlight mw-highlight-lang-csharp mw-content-ltr" dir="ltr"><span class="na">[AutoValidateAntiforgeryToken]</span></code>

</td>

<td>Validiert das CSRF-Token für alle HTTP-Methoden ausgenommen <code>GET</code>, <code>HEAD</code>, <code>OPTIONS</code>, <code>TRACE</code>. Hierbei müssen die entsprechenden Methoden standardkonform implementiert werden.

</td></tr>

<tr>

<td><code class="mw-highlight mw-highlight-lang-csharp mw-content-ltr" dir="ltr"><span class="na">[IgnoreAntiforgeryToken]</span></code>

</td>

<td>Keine Validierung

</td></tr></tbody></table>

<p>Filter auf den Methoden überschreiben hierbei die Filter auf den Controllern.

</p>

<div class="mw-heading mw-heading4"><h4 id="Cookie">Cookie</h4></div>

<p>Das CSRF-Token kann auch in einem <a href="HTTP-Cookie" title="HTTP-Cookie">Cookie</a> gespeichert werden. Dieses wird im HTTP-Header deklariert:

</p>

<div class="mw-highlight mw-highlight-lang-http mw-content-ltr" dir="ltr"><pre><span></span><span class="err">Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2017 10:25:33 GMT; Max-Age=31449600; Path=/</span>

</pre></div>

<p>Das Flag <code>httpOnly</code> ist hierbei nicht zulässig, da das Token im Browser durch ein <a href="JavaScript" title="JavaScript">JavaScript</a>-Skript verarbeitet werden muss.

</p><p>Bestimmte Frameworks erzwingen eine bestimmte Benennung für das CSRF-Cookie. Beispielsweise muss das Token für das <code>$http</code>-Service in <a href="Angular" title="Angular">Angular</a> mit <code>XSRF-TOKEN</code> benannt werden. Anschließend wird das Token im <code>X-XSRF-TOKEN</code>-HTTP-Header übermittelt.<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

</p><p><b>Beispiel in ASP.NET MVC</b>

</p><p>Mit <code>Microsoft.AspNetCore.Antiforgery</code> lässt sich das Cookie wie folgt setzen:

</p>

<span class="w"> </span><span class="n">options</span><span class="p">.</span><span class="n">CookieName</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">"Csrf-Token"</span><span class="p">;</span>

<span class="w"> </span><span class="n">options</span><span class="p">.</span><span class="n">CookiePath</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">"/"</span><span class="p">;</span>

<span class="w"> </span><span class="n">options</span><span class="p">.</span><span class="n">CookieDomain</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">"example.com"</span><span class="p">;</span>

</pre></div>

<div class="mw-heading mw-heading4"><h4 id="HTTP-Header">HTTP-Header</h4></div>

<p>Eine weitere Methode, das Token zu übermitteln, ist der <a href="HTTP-Header" class="mw-redirect" title="HTTP-Header">HTTP-Header</a>. Hierzu wird der Header <code>X-Csrf-Token</code> verwendet. Allerdings verwenden einige Frameworks auch vom Standard abweichende Header.

</p>

<caption>Beispiele für Frameworks mit nicht-standardisierten CSRF-Header

</caption>

<th>Header</th>

<th>Framework

</th></tr>

<tr>

<td><code>X-XSRF-TOKEN</code></td>

<td><a href="Angular" title="Angular">Angular</a>

</td></tr>

<tr>

<td><code>X-Requested-With</code></td>

<td><a href="JQuery" title="JQuery">jQuery</a>

</td></tr>

<tr>

<td><code>X-Requested-By</code></td>

<td><a rel="nofollow" class="external text" href="https://jersey.github.io/">Jersey</a>

</td></tr></tbody></table>

<p><b>Beispiel in ASP.NET MVC</b>

</p><p>Mit <code>Microsoft.AspNetCore.Antiforgery</code> lässt sich das Token im HTTP-Header wie folgt setzen:

</p>

<span class="w"> </span><span class="n">options</span><span class="p">.</span><span class="n">HeaderName</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">"X-Csrf-Token"</span><span class="p">;</span>

</pre></div>

<div class="mw-heading mw-heading4"><h4 id="Behandlung_von_XMLHttpRequests">Behandlung von XMLHttpRequests</h4></div>

<p>Bei alten Browsern, die <code>XMLHttpRequest</code>s von verschiedenen Origin-Domänen zulassen, müssen <code>XMLHttpRequest</code>s abgelehnt werden, wenn die im Origin-HTTP-Header eingetragene Domäne nicht Teil der zulässigen <a href="Cross-Origin_Resource_Sharing" title="Cross-Origin Resource Sharing">CORS</a>-Domänen ist.

</p>

<div class="mw-heading mw-heading3"><h3 id="Clientseitig">Clientseitig</h3></div>

<p>Viele Webanwendungen, wie zum Beispiel auch die Wikipedia, bieten ihren Nutzern die Möglichkeit, dauerhaft angemeldet zu sein. Technisch wird hierbei in der Regel der in einem Cookie gespeicherte Sitzungsbezeichner am Ende einer Sitzung nicht gelöscht. Diese Komfortfunktion vergrößert aber auch die Angriffsfläche, da der Angreifer nicht mehr einen Zeitpunkt abzupassen braucht, zu dem sein Opfer an der Webanwendung angemeldet ist. Der Verzicht auf diese Funktion erhöht folglich die Hürden, die der Angreifer nehmen muss.

</p>

<div class="mw-heading mw-heading2"><h2 id="Unzulängliche_Abwehrmaßnahmen"><span id="Unzul.C3.A4ngliche_Abwehrma.C3.9Fnahmen"></span>Unzulängliche Abwehrmaßnahmen</h2></div>

<p>Einige Maßnahmen zur Unterbindung von CSRF-Angriffen reichen nicht aus, um einen hinreichenden Schutz zu gewährleisten. Sie sind bestenfalls dazu geeignet, die Hürde für den Angreifer etwas höher zu hängen, und wiegen den Betreiber einer Webanwendung schlimmstenfalls in Scheinsicherheit.

</p>

<div class="mw-heading mw-heading3"><h3 id="HTTP-Referrer-Prüfung"><span id="HTTP-Referrer-Pr.C3.BCfung"></span>HTTP-Referrer-Prüfung</h3></div>

<p>Die Prüfung des HTTP-<a href="Referrer" title="Referrer">Referrer</a>-Headers bietet zwar einen gewissen Schutz vor reinen CSRF-Angriffen, da gefälschte Anfragen, die von einem Angreifer mittels Täuschung des Opfers auf einer externen Webseite ausgelöst wurden, zum Teil blockiert werden können. Die Webanwendung ist jedoch gut beraten, sich nicht auf den Schutz des Referrers zu verlassen: Viele Browser-Plugins erlauben es nämlich, Anfragen mit beliebigem Referrer abzusetzen, z. B. das früher weit verbreitete <a href="Adobe_Flash" title="Adobe Flash">Adobe Flash</a><sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>. Außerdem können Benutzer oder auch Proxy-Server aus Datenschutzgründen das Übertragen des Referrers unterbinden oder gezielt einen anderen Wert eintragen, wodurch die Web-Anwendung nicht mehr allen legitimen Anwendern offensteht (<a href="False_positive" class="mw-redirect" title="False positive">false positives</a>). Aus Gründen der Benutzbarkeit einer Webanwendung sollte man den Referrer-Header grundsätzlich nicht für eine HTTP-Anfrage verwenden.

</p>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Norman Hardy: <a rel="nofollow" class="external text" href="https://portal.acm.org/citation.cfm?id=871709">The Confused Deputy: (or why capabilities might have been invented).</a> In: <i>ACM SIGOPS Operating Systems Review</i>, Oktober 1988, Volume 22, Issue 4.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="https://www.cubespotter.de/cubespotter/csrf-attacks-teil2-schwache-gegenmassnahmen/">CSRF Angriffe (Teil 2): <i>Schwache Gegenmaßnahmen</i>.</a> cubespotter.de, Juni 2017.</li>

<li><a rel="nofollow" class="external text" href="https://www.heise.de/developer/artikel/Querschau-der-Risiken-1028917.html"><i>Querschau der Risiken</i>.</a> Heise, 2010.</li>

<li><a rel="nofollow" class="external text" href="https://www.owasp.org/images/9/90/OWASP_Top_10-2017_de_V1.0.pdf">OWASP Top 10-2017.</a> (PDF) Open Web Application Security Project.</li>

<li><a rel="nofollow" class="external text" href="https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html">Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet.</a> OWASP.</li>

<li><a rel="nofollow" class="external text" href="http://nvd.nist.gov/">National Vulnerability Database web site.</a> nist.gov</li>

<li><a rel="nofollow" class="external text" href="http://www.squarefree.com/securitytips/web-developers.html">Security tips for Web developers.</a> squarefree.com (englisch).</li>

<li><a rel="nofollow" class="external text" href="https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/WebSec/WebSec.pdf?__blob=publicationFile&v=1">Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen.</a> (PDF; 922 kB) Bundesamt für Sicherheit in der Informationstechnik (BSI).</li>

<li><a rel="nofollow" class="external text" href="https://www.erich-kachel.de/?p=368">Session-Angriffe – eine Analyse.</a> erich-kachel.de</li>

<li><a rel="nofollow" class="external text" href="https://www.tecchannel.de/webtechnik/webserver/1993878">CSRF-Angriffe auf Router und Webanwendungen.</a> TecChannel, 2009.</li>

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2616#section-9.1.1" class="extiw external" title="rfc:2616">2616</a></span></i> – <i><span lang="en">Hypertext Transfer Protocol – HTTP/1.1</span></i>. Juni 1999, Abschnitt 9.1.1: <i>Safe Methods</i>. (englisch).</li>

<li><a rel="nofollow" class="external text" href="http://www.cgisecurity.com/csrf-faq.html">The Cross-site Request Forgery FAQ.</a> cgisecurity.com</li>

<li>Sverre Huseby: <a rel="nofollow" class="external text" href="http://shh.thathost.com/text/client-side-trojans.txt">Client Side Trojans.</a> shh.thathost.com</li>

<li><a rel="nofollow" class="external text" href="http://shiflett.org/articles/foiling-cross-site-attacks">Foiling Cross-Site Attacks.</a> shiflett.org, 2003.</li>

<li><a rel="nofollow" class="external text" href="http://shiflett.org/blog/2005/session-riding">Concerns over the name “Session Riding”.</a> shiflett.org/blog, 2005</li>

<li><a rel="nofollow" class="external text" href="https://security.stackexchange.com/questions/234386/do-i-still-need-csrf-protection-when-samesite-is-set-to-lax">Do I still need CSRF protection when SameSite is set to Lax?</a> security.stackexchange.com, 2021.</li>

<li><a rel="nofollow" class="external text" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies">Using HTTP cookies</a> developer.mozilla.org/en-US/docs/, 2024.</li>

<li><a rel="nofollow" class="external text" href="https://www.heise.de/news/SameSite-Attribut-Google-Chrome-draengt-auf-sichere-Cookies-4768780.html">SameSite-Attribut: Google Chrome drängt auf sichere Cookies</a> www.heise.de/news, 2020.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text"><span class="cite">Peter Watkins: <a rel="nofollow" class="external text" href="https://web.archive.org/web/20120709094554/http://www.tux.org/~peterw/csrf.txt"><i>Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images).</i></a> Bugtraq, 13. Juni 2001, archiviert vom <span class="dewiki-iconexternal"><a class="external text" href="https://redirecter.toolforge.org/?url=http%3A%2F%2Fwww.tux.org%2F%7Epeterw%2Fcsrf.txt">Original</a></span> (nicht mehr online verfügbar) am <span style="white-space:nowrap;">9. Juli 2012</span><span>;</span><span class="Abrufdatum"> abgerufen am 26. Juli 2012</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ACross-Site-Request-Forgery&rft.title=Cross-Site+Request+Forgeries+%28Re%3A+The+Dangers+of+Allowing+Users+to+Post+Images%29&rft.description=Cross-Site+Request+Forgeries+%28Re%3A+The+Dangers+of+Allowing+Users+to+Post+Images%29&rft.identifier=https%3A%2F%2Fweb.archive.org%2Fweb%2F20120709094554%2Fhttp%3A%2F%2Fwww.tux.org%2F%7Epeterw%2Fcsrf.txt&rft.creator=Peter+Watkins&rft.publisher=Bugtraq&rft.date=2001-06-13&rft.source=http://www.tux.org/~peterw/csrf.txt&rft.language=en"> </span></span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a></span> <span class="reference-text">Christian Schneider: <a rel="nofollow" class="external text" href="http://www.christian-schneider.net/CsrfAndSameOriginXss.html"><i>CSRF and Same-Origin XSS.</i></a> 25. Februar 2012; abgerufen am 13. Dezember 2014.</span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><a href="#cite_ref-3">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://angular.io/docs/ts/latest/guide/server-communication.html#!#xsrf"><i>Guarding against Cross-Site Request Forgery.</i></a> In: <i>Angular.io.</i> Google,<span class="Abrufdatum"> abgerufen am 15. Mai 2017</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ACross-Site-Request-Forgery&rft.title=Guarding+against+Cross-Site+Request+Forgery&rft.description=Guarding+against+Cross-Site+Request+Forgery&rft.identifier=https%3A%2F%2Fangular.io%2Fdocs%2Fts%2Flatest%2Fguide%2Fserver-communication.html%23%21%23xsrf&rft.publisher=Google&rft.language=en"> </span></span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20130104232934/http://www.securiteam.com/securityreviews/5KP0M1FJ5E.html"><i>Forging HTTP Request Headers with Flash ActionScript.</i></a> In: <i>securiteam.com.</i> 4. Januar 2013, archiviert vom <span class="dewiki-iconexternal"><a class="external text" href="https://redirecter.toolforge.org/?url=http%3A%2F%2Fwww.securiteam.com%2Fsecurityreviews%2F5KP0M1FJ5E.html">Original</a></span> (nicht mehr online verfügbar) am <span style="white-space:nowrap;">4. Januar 2013</span><span>;</span><span class="Abrufdatum"> abgerufen am 24. Januar 2022</span>.</span> <small class="archiv-bot"><span class="wp_boppel noviewer" aria-hidden="true" role="presentation"><span typeof="mw:File"><span title="i"></span></span></span> <b>Info:</b> Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.</small><span style="display:none"><a rel="nofollow" class="external text" href="http://IABotmemento.invalid/http://www.securiteam.com/securityreviews/5KP0M1FJ5E.html">@1</a></span><span style="display:none"><a rel="nofollow" class="external text" href="http://www.securiteam.com/securityreviews/5KP0M1FJ5E.html">@2</a></span><span style="display:none">Vorlage:Webachiv/IABot/www.securiteam.com</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ACross-Site-Request-Forgery&rft.title=Forging+HTTP+Request+Headers+with+Flash+ActionScript&rft.description=Forging+HTTP+Request+Headers+with+Flash+ActionScript&rft.identifier=https%3A%2F%2Fweb.archive.org%2Fweb%2F20130104232934%2Fhttp%3A%2F%2Fwww.securiteam.com%2Fsecurityreviews%2F5KP0M1FJ5E.html&rft.date=2013-01-04&rft.source=http://www.securiteam.com/securityreviews/5KP0M1FJ5E.html"> </span></span>

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-10-16" href="https://de.wikipedia.org/wiki/?title=Cross-Site-Request-Forgery&oldid=260640963">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>